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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



rd , 



The present document is part of a TS-family covering the 3 Generation Partnership Project; Technical Specification 
Group Services and System Aspects; Telecommunication management; as identified below: 

32.121: Advanced Alarm Management (AAM) Integration Reference Point (IRP): Requirements; 

32.122: Advanced Alarm Management (AAM) Integration Reference Point (IRP): Information 

Service (IS); 

32. 123: Advanced Alarm Management (AAM) Integration Reference Point (IRP): Common Object 

Request Broker Architecture (CORBA) Solution Set. 

The Itf-N interface is built up by a number of IRPs and a related Name Convention, which realize the functional 
capabilities over this interface. The basic structure of the IRPs is defined in 3GPP TS 32.150 [1]. 

A single network fault may generate a large number of alarms over space and time. In a large and complex network, 
simultaneous network faults may occur, causing the network operator to be flooded with high volume of alarms. 
The high volume of alarms, typically the one received by an IRPManager via the getAlarmList or alarm 
notifications of Alarm IRP specification, greatly inhibits the operator ability to quickly identify and locate the 
responsible network faults. AAM IRP is intended to provide methods to improve this situation. 
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Scope 



The purpose of Advanced Alarm Management (AAM) IRP is to define an interface through which an IRPManager 
can categorize alarm notifications. 

The present document is the Information Service of AAM. It defines, for the purpose of categorizing alarm 
notifications, the information observable and controlled by management system's client and it also specifies the 
semantics of the interactions used to carry this information. 



References 



The following documents contain provisions that, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document 
(including a GSM document), a non-specific reference implicitly refers to the latest version of that document in 
the same Release as the present document. 

[1] 3GPP TS 32.150: "Telecommunication management; Integration Reference Point (IRP) Concept 

and definitions". 

[2] 3GPP TS 32.102: "Telecommunication management; Architecture". 

[3] 3GPP TS 32.302: "Telecommunication management; Configuration Management (CM); 

Notification Integration Reference Point (IRP): Information Service (IS)". 

[4] 3GPP TS 32.121: "Telecommunication management; Advanced Alarm Management Reference 

Point (IRP): Requirements". 

[5] 3GPP TS 32.150: "Telecommunication management; Integration Reference Point (IRP) Concept 

and definitions". 

[6] 3GPP TS 32.622: "Telecommunication management; Configuration Management (CM); Generic 

network resources Integration Reference Point (IRP): Network Resource Model (NRM)". 

[7] 3GPP TS 32.312: "Telecommunication management; Generic Integration Reference Point (IRP) 

management; Information Service (IS)". 

[8] 3GPP TS 32.602: "Telecommunication management; Configuration Management (CM); Basic CM 

Integration Reference Point (IRP): Information Service (SS)". 

[9] 3GPP TS 32.662: "Telecommunication management; Configuration Management (CM); Kernel 

CM; Information service (IS)". 
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3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

IRP: See 3GPP TS 32.150 [1]. 

IRPAgent: See 3GPP TS 32.150 [1]. 

IRPManager: See 3GPP TS 32.150 [1]. 

Alike Alarm: Two alarms are considered alike, if the corresponding alarm notifications are issued by the same object 
instance with the same alarmType, same perceivedSeverity, same probableCause and same 
specif icProblem (if present). 

Lower Edge of Time Window: The point in time which determines the begin of a time span. 

Upper Edge of Time Window: The point in time which determines the end of a time span. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AAM Advanced Alarm Management 

AAMRule Advanced Alarm Management Rule 

CM Configuration Management 

EM Element Manager 

IOC Information Object Class 

IRP Integration Reference Point 

IS Information Service 

Itf-N Interface N 

MIB Management Information Base 

NE Network Element 
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4 System overview 

4.1 System context 

The general definition of the System Context for the present IRP is found in 3GPP TS 32.150 [5], clause 4.7. 
In addition, the set of related IRP(s) relevant to the present IRP is shown in figures 4.1-1 and 4.1-2. 
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Figure 4.1-1 : System Context A 
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Figure 4.1-2: System Context B 
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5 

5.1 



Information Object Classes 

Imported information entities and local labels 



Label reference 


Local label 


3GPP TS 32.622 [6], information object class, Top 


Top 


3GPP TS 32.312 [7], information object class, managedGenericIRP 


managedGenericIRP 


3GPP TS 32.622 [6], information object class, iRPAgent 


IRPAgent 



5.2 Class diagram 

5.2.1 Attributes and relationships 

This clause depicts the set of lOCs that encapsulate information within the AAM IRP. The intent is to identify the 

information required for the AAM IRP implementation of its operations and notification emission. 

This clause provides the overview of all Information Object Classes in UML. 

Subsequent clauses provide more detailed specification of various aspects of these Information Object Classes. 



^InformationObjectClass^ 
Ad va n ce clA I ar m M a na g e m e ntl RP 



■l." 



«lrformationObjectClass» 
AdvancedAlarmfvlana gementRule 



aAMRuleldentifier 
aAMRuleType 
aAMRuleParameterList 
filter 



Figure 5.2.1-1 : Class Diagram 
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5.2.2 Inheritance 

This clause depicts the inheritance relationships that exist between Information Object Classes. 



«lnfonnationOhijec"tClass>> 

ManagedG enericIRP 
(from 32.622} 



A 



«lnfonnationObjectClass» 
AdvancedAlarmManage mertl RP 



Figure 5.2.2-1 : Inheritance Diagram 
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5.3 Information Object Class definitions 

5.3.1 advancedAlarmManagementRule 



5.3.1.1 



Definition 



5.3.1.1.1 General Definition 

This information object represents an AAM Rule object instance. 

An AdvancedAlarmManagementRule is fully identified by its distinguished name. 

It inherits from IOC top. 

An AAM Rule is a way for the IRPManager to define which alarms / alarm clearings deliver significant or 
insignificant information (significant seen with the eyes of the IRPManager) and to tell the IRPAgent not to send 
the insignificant alarms / alarm clearings. 

AAMRules will not screen out all insignificant alarms/alarm clearings, but contribute to enable the network operator to 
reduce the number of reported alarms to a reasonable and manageable level. 

The choice of rule/s may depend on the type of alarm, the environment, the time of day and many more. 

To avoid screening of alarms which might be important for the network operator, the user of AAM rules should apply 
AAMrules with careful consideration and appropriate setting of parameters. 

An AAM Rule instance is fully identified by its DNdistinguished name. A Rule instance carries, among other things, 
the identification of the Rule type called AdvancedAlarmManagementRuleType. Of these there exist the 
following: 

• ThresholdRule 

• TransientRule 

• ToggleRule 

• VendorSpecificRule 

See Annex A for the description of the above Rules. 



5.3.1.2 



Attributes 



Attribute name 


Support Qualifier 


Read Qualifier 


Write Qualifier 


advancedAlarmManagementRule Identifier 


M 


M 


- 


advancedAlarmManagementRuleType 


M 


M 


- 


advancedAlarmManagementRuleParameterList 


M 


M 


- 


filter 


M 


M 


- 



5.3.2 advancedAlarmManagementIRP 
5.3.2.1 Definition 

This information object represents an AAM IRP. It inherits from IOC managedGenericIRP. 
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5.4 Information relationships definition 

5.4.1 relation- AdvancedAlarmManagementlRP-AdvancedAlarm 
ManagementRule (M) 



5.4.1.1 



Definition 



This relationship defines the relationship between an AdvancedAlarmManagementIRP and an 
AdvancedAlarmManagementRule instance. 



5.4.1.2 



Roles 



Name 


Definition 


theAdvancedAlarmManagementRule 


This role represents an AAM Rule. It can be played by instances of IOC 

advancedAlarmingRule 


theAdvancedAlaritiManagementlRP 


This role represents the AAM IRP which an iRPManager uses. It is played by 
instances of IOC advancedAlarm Management IRP 



5.4.1.3 

None 



Constraints 



5.5 



Information attributes definition 



This clause defines the semantics of the Attributes used in Information Object Classes. 

5.5.1 Definitions and legal values 



Attribute Name 


Definition 


Legal 
Values 


advancedAlarmManagementRuleldentif ier 


This attribute identifies uniquely an AAM Rule base 
object instance 


String 


advancedAlarmManagementRuleType 


This attribute indicates the type of AAM Rule this 
instance represents. 


String 


advancedAlarmManagementRuleParameterList 


This attribute identifies parameters and values of this 
AAM Rule 


N/A 
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Interface Definition 



6.1 Class diagram representing interfaces 



<<lnfomiationOhjectClass>> 

AdvancedAlarmManagementIRP 



i 



<<lnterface>> 

Advanced Ala imM anageme ntlRPOperati an_1 



activateMMRuleO 

deactivateAAMRuleO 

getAAMRulesQ 



Figure 6.1-1: Class Diagram for AdvancedAlarmManagementlRPOperationI Interface 
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6.2 AAMIRPOperation_1 Interface (M) 

6.2.1 Scope 

This interface defines methods for the IRPManagerlRPManager to request for alarm notifications of significant 
information (significant from the IRPManager's perspective). 

The definition of insignificance is determined by the IRPManager. The choice of AAM Rule/s may depend on the 
type of alarm, the environment, the time of day and many more. 

An implementation can claim compliance to this IRP if it supports at least one of the AAMRules, i.e. one of the 
operations defined in clause 6.2.2 up to and including clause 6.2.5, and the mandatory operations defined in this 
interface. 

6.2.2 Operation activateAAMRule (M) 
6.2.2.1 Definition 

This operation allows an IRPManager to activate an AAM rule (see §A.3.1.1.2.1). 



6.2.2.2 



Input parameters 



6.2.2.2.1 Generic Input parameters 



Parameter Name 


Qualifier 


Information 
type 


Comment 


aAMRuleType 


M 


N/A 


This corresponds to attribute 

advancedAlarmManagementRuleType of 
advancedAlarmManagementRule (see 5.3.1.2) 
Values: ThresholdRule, TransientRule, ToggleRule, 
VendorSpecif icRule 


aAMRuleParameterList 


M 


N/A 


This corresponds to attribute 

advancedAlarmManagementRuleParameterList of 
advancedAlarmManagementRule (see 5.3.1.2) 
Content depends on value of 

advancedAlarmManagementRuleType 


filter 


M 


N/A 


This corresponds to attribute filter of 
advancedAlarmManagementRule (see 5.3.1.2) 
Carries a filter constraint. It can e.g. comprise obj ectciass , 
objectlnstance, alarmType, probableCause, 
perceivedSeverity, specif icProblem. 



6.2.2.2.2 Content of Input parameter aAMRuleParameterList depending on value 
of aAMRuleType 

6.2.2.2.2.1 aAMRuleType = ThresholdRule 



Parameter Name 


Qualifier 


Information 
type 


Comment 


alarmOccurenceThreshold 


M 


N/A 


value >0 


slidingTimeWindow 


M 


N/A 


Unit: minutes 
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6.2.2.2.1.2 aAMRuleType = TransientRule 



Parameter Name 


Qualifier 


Information 
type 


Comment 


timeSpan 


M 


N/A 


Unit: minutes 



6.2.2.2.2.3 aAMRuleType = ToggleRule 



Parameter Name 


Qualifier 


Information 
type 


Comment 


alarmOccurenceThreshold 


M 


N/A 


value>0 


slidingTimeWindowTogglingStarted 


M 


N/A 


Unit: minutes 


slidingTimeWindowTogglingSettled 


M 


N/A 


Unit: minutes 



6.2.2.2.2.4 aAMRuleType = vendorSpecif icRule 



Parameter Name 


Qualifier Information type Comment 


vendor specific parameters 


N/A 


N/A 


N/A 



6.2.2.3 Output parameters 



Parameter Name 


Qualifier 


Matching Information 


Comment 


aAMRuleldentif ier 


M 


N/A 


See §5.5.1 


status 


M 


ENUIVI (Success, Failure, aAMRuleAlreadyActive) 





6.2.2.4 Pre-condition 

AAMIs Supported 



Assertion Name 


Definition 


aAMIsSupported 


The AAIVI functionality is supported by the iRPAgent. 



6.2.2.5 Post-condition 

AAMRulelsApplied 



Assertion Name 



Definition 



aAMRulelsApplied 



The AAIVI rule is applied. For the consequences see the definitions in Annex A. 



6.2.2.6 Exceptions 



Name 


Properties 


operation failed 


Condition: the pre-condition is false or the post-condition is false. 
Returned Information: The output parameter status. 
Exit state: Entry state. 
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6.2.3 Operation getAAMRules (M) 



6.2.3.1 Definition 

This operation allows an IRPManager to request from the IRPAgent a list of activated AAMRules. 



6.2.3.2 

None 

6.2.3.3 



Input parameters 



Output parameters 



Parameter 
Name 


Qualifier 


Matching Information 


Comment 


aAMRuleList 


M 


LlSTof aAMRulelnstance { 

aAMRulelnstance 
LIST OF { 

aAMRuleldentif ier, 
aAMRuleType, 
aAMRuleParameterList, 
filter 

} 

aAMRuleType 
ENUM( 

thresholdRule , 
toggleRule, 
transientRule, 
vendorSpecif icRule 

) 

aAMRuleParameterList: 
Content type depends on the value of 

aAMRuleType (see §6.2.2) 




Status 


M 


ENUM (Success, Failure) 


If no rule is defined, an empty 

advancedAlarmManagement 
RuleList a shall be delivered and 

status==Success. 



6.2.3.4 

None 



Pre-condition 



6.2.3.5 Post-condition 

allActiveAdvanceAlarmManagementRulesAreDelivered 



Assertion Name 


Definition 


allActiveAlarmManagementRulesAreDelivered 


All active aam rules are listed in the output. 



6.2.3.6 



Exceptions 



Name 


Properties 


operation failed 


Condition: the pre-condition is false or the post-condition is false. 
Returned Information: The output parameter status. 
Exit state: Entry state. 



£75/ 



3GPP TS 32.122 version 9.0.0 Release 9 



17 



ETSI TS 132 122 V9.0.0 (2010-02) 



6.2.4 Operation deactivateAAMRule (M) 
6.2.4.1 Definition 

This operation allows an IRPManager to request from the IRPAgent to deactivate one or all activated AAMRules. 
Deactivated rules are not visible for the IRPManager. 



6.2.4.2 



Input parameters 



Parameter Name 


Qualifier 


Information 
type 


Comment 


advancedAlarmManagementRuleldentif ier 


M 


See 32.302 
[3] 


If this parameter contains no information, 
then all active AAIVI Rules shall be 
deactivated. 



6.2.4.3 



Output parameters 



Parameter 
Name 


Qualifier 


Matching Information 


Comment 


status 


M 


ENUM (Success, 

Specif ledRuleNotExi sting, 

Failure) 


If input parameter 

advancedAlarmManagementRule Identifier is 
present and no such rule exists, then status== 
Specif iedRuleNotExi sting. 
If input parameter 

advancedAlarmManagementRuleldentif ier is not 
present and no rule is defined, then status==Success. 



6.2.4.4 

None 



Pre-condition 



6.2.4.5 Post-condition 

allOrSpecif iedActiveAdvanceAlarmManagementRulesAreDeactivated 



Assertion Name 



Definition 



allOrSpecif iedActiveAdvanceAlarmManagementRulesAreDeactivated 



Depending on the input all or only 
the specified active AAIVI Rule are/is 
deactivated 



6.2.4.6 



Exceptions 



Name 


Properties 


operation failed 


Condition: the pre-condition is false or the post-condition is false. 
Returned Information: The output parameter status. 
Exit state: Entry state. 
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Annex A (normative): 

Advanced Alarm Management Rules 

A.1 General 

It is not recommended to have several AAMRules applicable at one time for one event. However, if YyyFunction 
supports and allows it, then it is vendor specific which AAMRule is applied or not. 

An AAMRule (called Rule hereafter) contains multiple elements. 

The first element (subsection titled: Criterion to determine alike alarm) is a criterion used to determine if an alarm 
is classified as 'alike' or "not alike". If the alarm is not-alike, then the alarm is not subject to further scrutiny 
(processing) by the Rule, i.e. it would be processed as if there is no Rule in effect. The IRPManager specifies such 
criterion in an input parameter named filter in various relevant AAM operations. 

The second element (subSection titled: Treatment of alike alarm) is the algorithm to determine if 

a) An alike alarm should be reported as one alarm (i.e. it is a significant alarm) or 

b) The alike alarm should be suppressed (i.e. it is an insignificant alarm). 
When a significant alarm is identified, the algorithm also determines: 

a) The time when the notifyNew/Changed/ClearedAlarm of this significant alarm should be sent to 
IRPManager and 

b) The value of alarmRaisedTime, alarmChangedTime and alarmClearedTime parameters in the relevant 
notifyNew/Changed/ClearedAlarm of this significant alarm. 

The third element (subSection titled: Relation to Log and AlarmList) specifies which alarms shall enter into Log of 
LogIRP and AlarmList of AlarmlRP. 

Each of the following subsections defines a Rule using the three-element description outlined above. 

For each Rule, illustration samples, using symbols shown below, are given (titled: Samples). The thick horizontal line 
indicates a time-line. The dotted double-arrow line indicates a time parameter, if applicable. The '?' box indicates the 
alarm under investigation. The left-edge of a box corresponds to the alarmRaisedTime while the right-edge 
corresponds to the alarmClearedTime. So, the horizontal span of a box indicates the alarm active time span. 



Figure A.1-1 : Sample diagram notations 

Sometimes, a shaded box is drawn below the time line as below. Such shaded box indicates the identification of a 

significant alarm (to be reported alarm). 

The left-edge of the box indicates the time when the corresponding alarm notification is sent out. This emission time is 

not necessarily identical to the alarmRaised/ChangedTime within the alarm notification. 

The right-edge of a box indicates the time when the corresponding alarm clearing notification is sent out. This emission 

time is not necessarily identical to the alarmClearedTime within the alarm notification. 
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Figure A.1-2: Sample diagram notations 

For each Rule, use cases are given (subSection titled: Example for Use cases). 

For some Rules exception handling is defined (subSection titled: Exception Handling). 
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A.2 AAM Rules 



A.2.1 Threshold Rule 
A.2. 1.1 Parameters 

This Rule has three parameters, namely, the alarmOccurenceThreshold (called N here), the 
slidingTimeWindow (called T here) and filter. 

A.2.1 .2 Criterion to determine alike alarm 

The filter parameter carries values for obj ectlnstance , alarmType , perceivedSeverity , 
probableCause and specif icProblem. If the alarm under investigation (e.g. the box with a '?' in the sample 
below) carries the same values, then it is considered 'alike' otherwise, "not-alike". 

A.2.1 .3 Treatment of alike alarm 

Starting value for Lower Edge of Time Window is the activation time of the threshold rule. 

Test an alike alarm. 

When a new alarm matches the filter, then Lower and Upper Edge of Time Window and count are newly determined: 
Upper Edge of Time Window becomes the time of the new alarm. 

Lower Edge of Time Window becomes either the time of the current Lower Edge of Time Window or the time of the 
new alarm minus the default size T of the time window, whichever of these two times is later. 

The count is the number of alarms between Lower and Upper Edge of Time Window (including the new alarm). 

If the count reaches the threshold N, then the alarm is considered as significant and the Lower Edge of Time Window 

becomes the time of the alarm. 

For a not reported alarm no notif yClearedAlarm shall be sent. 

Notif yClearedAlarms for alarms which were reported to the IRPManager before the activation of the threshold 
rule shall not be suppressed. 

Table A.2. 1.3-1 shows the emission times of the various related to a significant alarm. 

Table A.2.1 .3-1 : Significant alarm emission time for Threshold Rule 



Reported alarm types 


Emission (to IRPManager) times of a reported alarm 


notifyNewAlarm 


Immediately after the alarmRaisedlime. 


notifyChangedAlarm 


Immediately after the alarmChangedlime. 


not if yClearedAlarm 


Immediately after the alarmClearedTime 



Table A. 2. 1.3-2 shows the time related parameters in significant alarm. 

Table A.2.1 .3-2: Significant alarm time parameters for Threshold Rule 



Parameters of the Reported alarm 


Parameter values 


alarmRaisedTime 


Same value as that carried in the alike alarm. 


alarmChangedTime 


Same value as that carried in the alike alarm. 


notifyClearedTime 


Same value as that carried in the alike alarm. 


alarmld 


Same value as that carried in the alike alarm. 
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A.2.1 .4 Relation to Log and AlarmList 

The alike alarms enter the Log. The significant alarms enter the AlarmList. 

A.2.1. 5 Samples 



N=3 
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FigureA.2.1 .5-1 : Threshold Rule illustrations - insignificant alarm 



N=3 
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FigureA.2.1. 5-2: Threshold Rule illustrations - insignificant alarm 



N=3 
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FigureA.2.1 .5-3: Threshold Rule illustrations - significant alarm 



A.2.1 .6 Example for Use cases 



The thresholdRule can be used to screen out alarms which are only important if they appear repeatedly, e.g. if an 
alarm which is self-healing comes back again and again, 
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A.2.2 Transient Rule 
A.2.2.1 Parameters 

This Rule has two parameters, namely, the minutesAtLeastActive (called T here) and filter. 

A.2.2. 2 Criterion to determine alike alarm 

The filter parameter carries values for objectlnstance, alarmXype, perceivedSeverity, probableCause and 
specificProblem. If the alarm under investigation (e.g. the box with a '?' in the sample below) carries the identified 
parameters and having the same values, then it is considered 'alike' otherwise, "not-alike". 

A.2.2. 3 Treatment of alike alarm 

Take an alike alarm. If it's period is smaller than T, then it is an insignificant alarm; otherwise, it is a significant alarm. 
For a not reported alarm no notifyClearedAlarm shall be sent. 

NotifyCleared Alarms for alarms which were reported to the IRPManager before the activation of the transientRule 
shall not be suppressed. 



Table A. 2. 2. 3-1 shows the emission times of the various related to significant alarm. 

Table A.2.2.3-1 : Significant alarm emission time re: Transient Rule 



Reported alarm type 


Emission (to IRPManager) times of an Reported alarm 


notifyNewAlarm 


Immediately after the alarmRaisedlime plus T. 


not i f yChangedAlarm 


Immediately after the alarmChangedlime plus T. 


notifyClearedAlarm 


Immediately after the alarmClearedlime 



Table A. 2. 2. 3-2 shows the time related parameters in significant alarm. 

Table A.2.2.3-2: Significant alarm time parameters re: Transient Rule 



Parameters of the Reported alarm 


Parameter values 


alarmRaisedTime 


Same value as that carried in the alike alarm. 


alarmChangedTime 


Same value as that carried in the alike alarm. 


notifyClearedTime 


Same value as that carried in the alike alarm 


alarmld 


Same value as that carried in the alike alarm. 



A.2.2.4 Relation to Log and AlarmList 

The alike alarms enter the Log. The significant alarms enter the AlarmList. 
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A.2.2.5 Samples 

Here are two samples. One is a not-to-be reported alarm while the other is a significant alarm. 



N=3 
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Figure A.2.2.5-1 : TransientRule Illustrations - insignificant alarm 



N=3 
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Figure A.2.2.5-2: TransientRule Illustrations - significant alarm 

A.2.2.6 Example for Use cases 

The transientRule can be used to screen out alarms which usually are of temporarily nature. 
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A.2.3 Toggle Rule 
A.2.3.1 Parameters 

This Rule has 4 parameters, namely, the filter, the alarmOccurenceThreshold (called N here), the 
slidingTimeWindowTogglingStarted (called Tl here) and slidingTimeWIndowTogglingSettled (called T2 here). 

A.2.3. 2 Criterion to determine alil^e alarm 

The filter parameter carries values for objectlnstance, alarmType, perceivedSeverity, probableCause and 
specificProblem. If the alarm under investigation (e.g. the box with a '?' in the sample below) carries the identified 
parameters and having the same values, then it is considered 'alike' otherwise, "not-alike". 

A.2.3. 3 Treatment of alike alarm 

1 . Starting values : 

Starting value for Lower Edges of Time Windows for Toggling Started/Settled is the activation time of the toggle rule. 

Starting value for the count is zero. 

At the beginning all alarms are "non-toggling" 

2. To do when alike alarm was identified 

When a notifyNew/Changed/ClearedAlarm event matches the filter, then Lower and Upper Edge of the Time Window 
TogglingStarted/Settled and count are newly determined: 

2. 1 . Determine Time Window TogglingStarted 

Upper Edge of Time Window TogglingStarted becomes the time of the event. 

Lower Edge of Time Window TogglingStartedbecomes the time of the event minus the size Tl of the time window. 

2.2. Determination of "toggling" (via count) 

The count is the number of alike alarms between Lower and Upper Edge of Time Window TogglingStarted (including 
the new alarm). 

If the count is above or equal to the threshold N and the event was a notifyNewAlarm and the alarm was "non- 
toggling", then the notifyNewAlarm is sent and the alarm is considered as "toggling", with the consequence that further 
alike notifyNew/Changed/ Alarm events are regarded as not significant, until the alarm is considered as "non-toggling" 
again. 

2. 3. Determine Time Window TogglingSettled 

If the alarm is "non- toggling", then there is no need to determine Upper and Lower Edge of Time Window 

TogglingSettled. 

If the alarm is "toggling", then: 

Upper Edge of Time Window TogglingSettled becomes the time of the new event plus the size T2 of the Time Window 

TogglingSettled . 

Lower Edge of Time Window TogglingSettled becomes the time of the new alarm . 

3. Return to non-toggling 

If the time reaches the Upper Edge of Time Window TogglingSettled, then the alarm is considered as "non-toggling", 
i.e. alike alarms are regarded as significant. 

If the last event was a notifyChanged/ClearedAlarm, then the change to "non-toggling" triggers the emission of the 
related notification. 



£75/ 



3GPP TS 32.122 version 9.0.0 Release 9 



25 



ETSI TS 132 122 V9.0.0 (2010-02) 



Table A. 2. 3. 3-1 shows the emission times of the various related to significant alarm. 

Table A.2.3.3-1 : Significant alarm emission time re: Toggle Rule 



Reported alarm types 


Emission (to IRPManager) times of an Reported alarm 


notifyNewAlarm 


Immediately after the alarmRaisedTime 


notifyChangedAlarm 


Immediately after the alarmChangedlime [Remark: If the alarm is toggling state, then the 
notifyChangeAlarm is dropped (not significant).] 


notifyClearedAlarm 


Immediately after the alarmClearedTime+T2 of the last alike alarm , if alarmClearedlime is 

earlier than alarmRaisedTime+T2 

or 

immediately after the alarmClearedlime of the last alike alarm, if this time is later than or 

equal to alarmRaisedTime+T2 



Table A. 2. 3. 3-2 shows the time related parameters in significant alarm. 

Table A.2.3.3-2: Significant alarm time parameters re: Toggle Rule 



Parameters of the Reported alarm 


Parameter values 


alarmRaisedTime 


Same value as that carried in the alike alarm. 


alarmChangedTime 


Same value as that carried in the alike alarm. 


notifyClearedTime 


Same value as that carried in the last alike alarm. 


alarmld 


Same value as that carried by the first member of a sequence. 



A.2.3.4 Relation to Log and AlarmList 

The alike alarms enter the Log. The significant alarms enter the AlarmList. 

A.2.3.5 Samples 

The samples below use N=3. 



N=3 



Tl 



T2 
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Figure A.2.3.5-1: Toggle Rule illustration 1 
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N=3 



Tl 



T2 
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Figure A.2.3.5-2: Toggle Rule illustration 2 



N=3 , T 1 ^ 



T2 
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Figure A.2.3.5-3: Toggle Rule illustration 3 



N=3 



Tl 
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Figure A.2.3.5-4: Toggle Rule illustration 4 



A.2.3.6 Example for Use cases 

The toggleRule can be used to take some burden from alarm management for cases where an alarm comes and goes 
back and forth, e.g. because of some entity is in a swinging state. 



A.2.3.7 Exception Handling 



The Toggle Rule can potentially group multiple alike alarms together to form one significant alarm. If the process 
executing the Rule misses the alarm clearing time of one member of a group, then this can have the following 
consequences: 
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If a clearing of one of the alike alarms during the toggling state is missed (green box in Figure A.2.3.7-1), then the 
significant alarm would also not be cleared (pink box continuing the dark grey in the same figure). This can be avoided 
if the filter is set in a way that only alarms of one instance will pass it and if always the latest notifyClearedAlarms 
triggers the start of T2. 
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Figure A.2.3.7-1 : Exception handling example 



A.2.4 Definition of vendor specific rule 

It is possible to implement vendor specific AAMRules. No specific definitions are supplied here. 
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A.3 Relation of Rule and Notification filter 

This clause illustrates the relation between the A AM capabilities and the NotificationIRP and AlarmlRP. 

The following diagram illustrates the case when AAM capabilities are not deployed. The "1, 2.. 6" indicates 6 alarms. 

They will be logged and they would appear in the AlarmList. The NotificationIRP supported a filter Fl. 

The IRPManager, in this case, receives "1, 3" where '2, 4, 5, 6' were discarded because of Notification filter Fl is in 

effect. 



i 



I 
F1 

NotificationIRP 



H ,2,3,4,5,6— AlarmlRP 



-1,2,3,4,5,6- 




AlarmList 



Figure A.3-1 : Deployment without AAM capabilities 

The following diagram illustrates the case when AAM capabilities are deployed. The "1, 2.. 6" indicates 6 alarms. 
They will be logged. Because of AAMRule Rl is in effect, the ""1,2. . .6" result in two significant alarms, A and B. 
The A and B will appear in AlarmList. They will also be broadcasted to IRPManagers subject to NotificationIRP 
filter in effect. In the case below, the IRPManager would receive only A because Notification IRP filter F2 is in 
effect. 
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FigureA.3-2: Deployment with AAM capabilities 
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